Mobile communications provides an access technology for portable user equipment (“UE”) to gain access to networks without having to use a wired connection. In today's environment, the UE communicates over a radio link to one or more network access points, often but not always those geographically nearest. One or more networks are available via the access points and these networks may be either wireless or fixed line.
An area in which considerable work has been done is in development of UMTS (“Universal Mobile Telecommunications System”) technology. The UMTS network architecture can be viewed as two primary parts, the UTRAN (“UMTS Terrestrial Radio Access Network”) and the core network. The UTRAN looks after the physical aspects of providing wireless access for a mobile UE to the core network and the core network provides switching. To use a UMTS network, the UE itself must be compatible and therefore includes in its operating environment protocols to support that wireless access.
Referring to FIG. 1, the UTRAN is made up of a set of RNSs (“Radio Network Subsystems”). Each RNS comprises one RNC (“Radio Network Controller”) and one or more logical nodes known as “Node Bs”. Each Node B is a network access point and its associated RNC generally controls the radio resources for providing wireless access across the air interface between a UE and the UTRAN, using the Node B.
Many protocols have been written in the course of mobile communications development. Many of these are used in the core network mentioned above. In order to use the core network, UMTS networks must be equipped with the relevant protocols demanded by the core network interface. However, the main thrust of today's UMTS networks lies in the UTRAN and its protocols to deal with the various radio/air interfaces between the RNCs, the Node Bs and the UEs. In a UMTS network, protocol stacks are used in each of the RNCs, the Node Bs and the UEs. One of these protocols is the Radio Link Control (“RLC”) protocol, present in the RNC and the UE.
One of the groups working on UMTS standards is the 3rd Generation Partnership Project (“3GPP”). An example of a technical specification published on the Internet by 3GPP that is relevant to embodiments of the present invention is as follows:
TS 25.322 (version 3.16.0, Release 1999)
entitled “Universal Mobile Telecommunications System (UMTS); Radio Link Control (RLC) protocol specification”. The versions of this specification for Releases 5 and 6 are also relevant.
The RLC protocol provides a number of services in supporting transfer of data units across the radio/air interfaces. In particular, it sets out behaviour of a sending entity and a receiving entity during the transfer of data units. A list of RLC services is set out in Section 5 of the above technical specification and includes for example flow and error control. Data is assembled into blocks (or “units” or “packets”) containing data with added control or signalling information.
In wireless communication systems such as UMTS, data can be lost or corrupted in the transmission. Some applications, such as real time applications, can tolerate at least a proportion of missing data packets but other applications cannot. The RLC protocol caters for these different situations by offering different modes of operation: transparent, unacknowledged and acknowledged. Acknowledged mode is designed for applications which require the receipt of correct data with no missing blocks. In acknowledged mode, every block to be transmitted has a sequence number carried in the control or signalling information and they are generally transmitted in ascending order of sequence numbers. Every block is checked by the receiving entity and status reports are returned to the transmitting entity containing positive and/or negative acknowledgements (“ACKs” and “NACKs”) with respect to the sequence numbers of blocks to be received. ACKs acknowledge receipt of correct blocks and NACKs trigger retransmission of missing or damaged blocks. However, the status reports are equally subject to the transmission problems of loss and corruption.
Although much has been done to deal with lost RLC signalling, such as TIMER_POLL to deal with a lost poll for a status report and TIMER_MRW to deal with a lost signal to move an existing transmission window, it has been recognised that there is at least one area the current RLC protocol doesn't cover adequately. Although TIMER_POLL will detect lost status reports which were sent in response to a poll, there has been nothing in place to detect lost status reports which have been triggered at the receiving end of a transmission, for example because incoming data blocks are corrupted or missing. This is particularly important where the status reports contain NACKs.
An initial solution was known as the “EPC” mechanism, standing for Estimated PDU Counter. (PDUs are further discussed below but in this context a PDU is a data block.) When a status report was sent out, the EPC mechanism did two things. It timed a period equivalent to the round trip time for a status report to trigger receipt of a retransmitted PDU. It also took current transmission rates into account by setting a counter to the estimated number of missing PDUs and then decrementing the counter at the rate of all incoming PDUs. At the end of the period and depending on the content of the counter, the safe receipt of the missing PDUs was checked and updated status reports were sent out for those still missing. The EPC mechanism was found unclear however and later abandoned.
Another, recently proposed solution is as follows. A receiving entity monitors the sequence numbers of received blocks. If blocks are missing or damaged, it sends a status report back to the transmitting entity, the report comprising NACKs identifying the missing or damaged blocks. At the same time, it sets a timer which times a period equivalent to the round trip for a NACK going to the transmitting entity and the transmitting entity responding. After the round trip period, if a block is now received with a later sequence number than any of the blocks subject to a NACK, there has only been a nil or partial response to the status report and the status report must have been damaged or lost. The receiving entity now sends a fresh status report and the process is repeated until all blocks are correctly received.
Both the EPC mechanism and this known proposed solution are not sufficient. Both rely on receiving further fresh blocks to be transmitted in order to deal with an error. They do not deal with the case where there are no more blocks transmitted from the transmitting entity, such as when the last block has been sent for some extended period of time. In practice, the proposed solution can, in certain circumstances, completely stall the transmission of data.
In more detail, stalling can arise as follows. The transmitting and receiving entities work within a shared, sliding transmission window of block sequence numbers. The transmitting entity will only send blocks whose numbers are in the window and these are the blocks the receiving entity expects to receive. When a sequence of blocks at the beginning of the window have been correctly received by the receiving entity, the transmission window is moved along to the next set of sequence numbers. If a status report identifying a lost or damaged block has itself been lost, then the transmitting entity may have stopped transmitting before the round trip time period has expired, simply because it has reached the end of the window. In this circumstance, after the round trip time period has expired, the receiving entity will never receive a block with a later sequence number than the blocks subject to a NACK in the lost status report. It will not be triggered to repeat the status report but neither will the transmission window be moved forward because not all the blocks in the current shared set of sequence numbers have been received.